crates/taskito-node/src/worker.rs (1)

94-96: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Stale comment: lifecycle loop no longer heartbeats.

This comment still describes the lifecycle loop as "registers/heartbeats", but heartbeats have been fully moved to JS (per the new module doc at Line 2-4) and the loop now only registers, waits on stop, then unregisters (Line 267). Worth updating to avoid confusing future readers about where heartbeats originate.

📝 Proposed comment fix

-    // The dispatcher reads cancel flags, and the lifecycle loop registers/heartbeats
+    // The dispatcher reads cancel flags, and the lifecycle loop registers/unregisters
     // — both need their own storage handle before `storage` moves into the scheduler.

Also applies to: 267-267

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/taskito-node/src/worker.rs` around lines 94 - 96, Update the stale
comment near dispatcher_storage in worker.rs so it no longer says the lifecycle
loop “registers/heartbeats”; the heartbeats now live in JS, and the Rust
lifecycle loop only registers, waits on stop, then unregisters. Keep the comment
aligned with the current behavior around the dispatcher storage clone and the
lifecycle loop so future readers can locate the responsibility split correctly.

crates/taskito-node/src/queue/inspect.rs (1)

129-149: 🚀 Performance & Scalability | 🔵 Trivial

Reaping on every heartbeat may not scale with worker count.

Each worker heartbeats independently (every ~5s), and each call unconditionally invokes storage.reap_dead_workers(). With N live workers, that's N reap scans every heartbeat interval instead of one global periodic reap — redundant load that grows with fleet size.

Consider throttling reaping (e.g., only reap if enough time elapsed since the last reap, tracked via a shared atomic/mutex on JsQueue or storage), or moving it to a single background interval decoupled from per-worker heartbeats.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/taskito-node/src/queue/inspect.rs` around lines 129 - 149, The worker
heartbeat path in worker_heartbeat currently triggers
storage.reap_dead_workers() on every call, which creates redundant reap scans as
worker count grows. Update the JsQueue/inspect flow so reaping is throttled or
centralized: either gate reaping with a shared last-reap timestamp/lock on
JsQueue or storage, or move it to a single background interval. Keep heartbeat
recording in worker_heartbeat intact and ensure the reap step remains
opportunistic without blocking or failing the heartbeat.

sdks/node/src/resources/health.ts (1)

8-8: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Health-checked resource set is frozen at start(); later registrations/replacements are invisible to the daemon.

checked is captured once from runtime.healthChecked() and reused for the timer's whole life. ResourceRuntime.register() explicitly supports replacing a definition on a live runtime, but if that happens after start() (e.g. a worker is already running), the new healthCheck/healthCheckIntervalMs/maxRecreationAttempts — or a brand-new health-checked resource registered later — never gets picked up by this already-running daemon.

Also, TICK_MS = 500 means no resource is ever checked more often than every 500ms, even if healthCheckIntervalMs is configured smaller (as several tests here do, e.g. 50/100ms) — worth documenting on ResourceDefinition.healthCheckIntervalMs.

♻️ Re-derive `checked` per tick

-    const checked = this.runtime.healthChecked();
-    if (checked.size === 0) {
-      return;
-    }
-    const now = Date.now();
-    for (const [name, def] of checked) {
-      this.nextDue.set(name, now + (def.healthCheckIntervalMs ?? 0));
-      this.failCount.set(name, 0);
-    }
-    this.timer = setInterval(() => void this.tick(checked), TICK_MS);
+    if (this.runtime.healthChecked().size === 0) {
+      return;
+    }
+    this.timer = setInterval(() => void this.tick(), TICK_MS);
     this.timer.unref();

and inside tick(), call const checked = this.runtime.healthChecked(); at the top, seeding nextDue/failCount lazily on first sight of a name.

Also applies to: 32-49

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@sdks/node/src/resources/health.ts` at line 8, The health daemon in
`HealthCheckDaemon` caches the result of `runtime.healthChecked()` once at
`start()`, so later `ResourceRuntime.register()` changes and newly added
health-checked resources are never observed; move the lookup into `tick()` and
re-derive `checked` each tick, initializing `nextDue` and `failCount` lazily for
newly seen names. Also account for `TICK_MS` as a hard polling floor by
documenting on `ResourceDefinition.healthCheckIntervalMs` that checks cannot run
more frequently than the daemon’s tick interval.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes